UMA technology enables alternative access to cellular mobile services, e.g. GSM (Global System for Mobile communication), WCDMA (Wideband Code Division Multiple Access) or GPRS (General Packet Radio Services) over an unlicensed spectrum, including WLAN (Wireless Local Area Network), Bluetooth™ and WiFi™. The UMA technology enables seamless delivery of mobile voice and data services over unlicensed wireless networks. The same mobile identity is provided on cellular radio access networks and unlicensed wireless networks, so that seamless transitions (e.g. roaming and handover) between these networks is possible.
In particular, UMA provides an extension of GSM/GPRS mobile services into the customer's premises that is achieved by tunneling certain GSM/GPRS protocols between the customer's premises and the core network over a broadband IP (Internet Protocol) network, and relaying them through an unlicensed radio link inside the customer's premises. UMA is a complement to traditional GSM/GPRS radio coverage, used to enhance customer premises coverage, increase network capacity and potentially lower costs. UMA constitutes a part of the radio access network and is introduced by adding a UMA Network Controller (UNC) as a link between the WLAN and the GSM core network using standard A and Gb interfaces. Hence, from the GSM core network's perspective, the UNC is perceived as just another Base Station Controller (BSC). The UNC functionality could also be introduced into existing BSC infrastructure, thus offloading the core network from signaling and multiple resource handling related to users shifting between WLAN and GERAN (GSM/EDGE Radio Access Network) in the same area.
In UMA, it is possible to put a call on hold, like in normal circuit-switched (CS) call. Real-time traffic, such as audio or video, of the CS domain user plane is received at the UNC via the Up interface and conforms to the RTP (Real Time Protocol) framing format defined in the IETF (Internet Engineering Task Force) specifications RFC 3267 and RFC 3551. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The data transport is augmented by the Real Time Control Protocol (RTCP) to allow monitoring of data delivery in a manner scalable to large multicast networks and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. An RTP packet consists of a fixed RTP header, a possibly empty list of contributing sources, and payload data. The RTP payload comprises the data transported by RTP in the RTP packet, for example, audio samples or compressed video data. The source of a stream of RTP packets is identified by a 32-bit numeric synchronization source (SSRC) identifier carried in the RTP header so as not to be dependent upon the network address. Additionally, a source of the stream of RTP packets that has contributed to the combined stream produced by an RTP mixer can be identified in a contributing source (CSRC) list. Such a list can be used, for example, in audio conferencing to identify all participants whose speech was combined to produce an outgoing packet, allowing the receiver to indicate the current talker, even though all audio packets contain the same SSRC identifier.
Additionally, the RTP header includes a payload type (PT) field of 7 bits, which identifies the format of the RTP payload and determines its interpretation by the application, a sequence number (SN) field of 16 bits, which is incremented by one for each RTP data packet sent and which may be used by the receiver to detect packet loss and to restore the original packet sequence, and a time stamp (TS) of 32 bits, which reflects the sampling instant of the first octet in the RTP packet. The sampling instant can be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations.
However, UMA Protocols (Stage 3) R1.0.4 require that a mobile terminal or user equipment (UE) sends RTP packets at least every 480 ms. During a holding state (call-on-hold) of the UE the audio encoding is stopped. Thus, there is no input to the RTP protocol to send to the network. Also, the UMA protocols do not describe at all how the call-on-hold situation should be handled in RTP packet point of view. In this regard, the UMA Protocols require that all RTP data traffic during one UMA call (including a call-on-hold situations) relates to the same RTP stream. This means RTP headers' SSRC and PT fields are identical, the TS field is incremented according to the payload decoding (will not be incremented if there is no payload) and the SN field is incremented in each packet.